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BUTTONS FOR PERSON TO PERSON PAYMENTS 

BACKGROUND OF THE INVENTION 
The invention relates generally to person-to-person money transfers, and 
more particularly facilitating money transfers related to listings at vending sites. 
5 One party may wish to transfer money to herself, a counter party, or vice 

versa, for any of a variety of reasons. For example, a payor may wish to give the money 
to the payee as a gift, or the payee may receive payment for an auction item sold to the 
payor. If the receiving party to the transfer is a merchant with a merchant credit card 
account, payment is received in the conventional way. Person-to-person payments apply 
Q 1 0 to situations where the receiver of the payment does not have access to a merchant credit 

card account. For example, the payee in a person-to-person transaction may be a 
01 merchant of goods without the ability to accept credit card payments directly because a 

|T| merchant credit card account is lacking. 

' Until recently for person-to-person payments, payors typically complete 

13 1 5 such payments via cash, check or money order because the payee does not have the 
ability to receive money electronically. Electronic payment methods are generally 
JjJ available to merchants, such as credit cards and bank account debits through electronic 

III fund transactions, however, the payor may not have access to these methods for whatever 

reason. For example, these electronic pajonent methods for merchants may require 
20 pvtrchasing hardware and/or software to support accepting payment. 

Auction sites, such as eBay™, provide action services that often involve 
parties without access to merchant account for accepting payment. Today, these parties 
often rely upon online money transfer systems. Often a button is inserted into auctions 
that the payor may activate to link to the onUne money transfer system. This button may 
25 embed a user identifier for the payee that is passed to the online money transfer system 
when the payor activates the link. The user identifier is used in one example to inform 
the online money transfer system who referred the payor. 

There are web sites that will auto-insert information into auction listings 
for various purposes. For example, an online money transfer system may insert buttons 
30 into all the auction listings for a particular user. The user provides the web site with a 
user name and password for the auction site and the web site finds all the active auction 
listings. A button is inserted into each active hsting associated with the user. 



BRIEF DESCRIPTION OF THE DRAWINGS 
The present invention is described in conjunction with the appended 

figures: 

FIG. 1 is a block diagram of an embodiment of an online money transfer 
5 system that is interfaced to a payor and payee; 

FIG. 2 is a block diagram of another embodiment of an online money 
transfer system; 

FIG. 3 is a block diagram of an embodiment of a payment enabler; 
FIG. 4 is a block diagram of an embodiment of a vending site; 
10 FIG. 5 is a flow diagram of an embodiment of a process for adding 

I* snippets to listings on the vending site; 

S FIG. 6 is a flow diagram of an embodiment of a process for a buyer paying 

%| for goods and/or services in the listing; and 

5fi 

CI FIG. 7 is a flow diagram of an embodiment of a process for automatically 

c a i 

jJJ 15 inserting snippets in hstings. 

In the appended figures, similar components and/or features may have the 
fy same reference label. Further, various components of the same type may be distinguished 

by following the reference label by a dash and a second label that distinguishes among the 
tl similar components. If only the first reference label is used in the specification, the 

20 description is applicable to any one of the similar components having the same first 
reference label irrespective of the second reference label. 

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 
The ensuing description provides preferred exemplary embodiment(s) 
only, and is not intended to limit the scope, applicability or configuration of the invention. 

25 Rather, the ensuing description of the preferred exemplary embodiment(s) will provide 
those skilled in the art with an enabling description for implementing a preferred 
exemplary embodiment of the invention. It being understood that various changes may 
be made in the fimction and arrangement of elements without departing fi-om the spirit 
and scope of the invention as set forth in the appended claims. 

30 The present invention facilitates online money transfers between payors 

and payees that use vending sites. Types of vending sites include auction sites, classified 
advertising sites, and other on-line sites that faciUtate person-to-person sales. When a 
party does not have access to a merchant account for accepting payment, they often rely 
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upon a payment enabler to allow the money transfer in these person-to-person sales. In 
various embodiments, the process of interacting with the payment enabler is facilitated 
with a snippet that may have a link and a button graphic associated therewith. These 
snippets allow the payor or purchaser to reduce the information manually entered into the 
payment enabler. A metahnk tool will add the snippet to all current and/or future listings 
at one or more vending sites. 

Referring first to FIG. 1, a block diagram of an embodiment of an on-line 
purchase system 100 is shown. Included in the system 100 are a vending web site 140, an 
online money transfer system 190, a sender 110, and a receiver 130. Respective 
computers 120 interface the sender 110 and receiver 130 to the Internet 150 or other wide 
area network such that they can interact with the vending site 140 and the money transfer 
system 190. Money hemdlers 160, a payment enabler 170 and user interfaces 180 make 
up the money transfer system 190. 

The vending site 140 is a web site coupled to the Internet 150 and may 
include servers and other computers as is well known in the art. The sender 1 10 points 
their browser to the vending site 140 to choose a purchase Hsting associated with the 
receiver 130. These Ustings could be classified advertisements, electronic advertisements 
or auctions. As is the case with some auctions, a listing may not be paid for until a period 
specified in the auction has expured. Although this embodiment shows the vending site 
140 being separate firom the money transfer system 190, other embodiments could 
combine these into the same location or spread portions of either among any number of 
locations. 

The transfer system 190 works in concert with the vending site 140 to help 
pay the selling party. It is noted that vending sites 140 do not typically support the 
insertion of buttons directly, but have certain features meant for manual manipulation that 
allow automation of the process by the payment enabler 170. When the purchaser wants 
to pay the selling party, the purchaser or payor interacts with the money transfer system 
190 to get money sent to the selling party or payee. To initiate sending money, the payor 
may contact the payment enabler 170 directly, may click a button in the listing or may 
respond to a button or link in a money request. Money handlers 160 are used to payin 
money for the buyer 1 10 or payout money for the seller 130. The user interfaces 180 
provide a variety of ways for the sender and receiver 1 10, 130 to interact with the transfer 
system 190. 



With reference to FIG. 2, a block diagram of an embodiment of an online 
money transfer system 190 is shown. The money transfer system 190 can be used for a 
variety of purposes, such as sending checks, sending greeting cards, sending payments for 
goods or services, or other situations where the receiver 130 may not have a merchant 
account for accepting electronic payment. In this embodiment, six handlers 160 and five 
user interfaces 180 are shown. Other embodiments could have more or less handlers 160 
and interfaces 180. Each of the h^idlers 160 allows a sender or receiver 110, 130 to add 
and/or remove money fi-om the payment enabler 170. Normally, the receiver 130 can 
choose the handler 160, but in some circumstances, the sender 110 can choose the handler 
160. For example, the sender may specify a particular gift certificate handler 160-6 that 
only allows the certificate to be used at a particular store for merchandise and/or services. 
The user interfaces 180 allow interaction with the payment enabler 170 to transfer money 
to and fi-om a stored value fimd. 

The promotion handler 160-1 allows adding and removing money in a 
form other than legal tender or negotiable instrument. Examples include airline mileage 
programs, prepaid phone cards. For example, a user could use money in their stored 
value fund to purchase airline miles with an airhne mileage handler 160-1. A conversion 
rate would be applied to convert the money to mileage credit. The promotion handler 
160-1 may need special information firom the payment enabler 170, such as the user's 
promotion account number, etc. Some of the interfaces 180 used to gain access to the 
payment enabler 170 could be used to also gain access to the vending site 140 to allow 
selecting a hstmg where a computer 120 may not be readily available to the sender 110. 

The credit and debit card handlers 160-2, 160-3 behave largely the same. 
Both can be used to add money into the payment enabler 170. In other embodiments, 
these handlers 160-2, 160-3 can also be used to remove money firom the payment enabler 
170 also, for example, to purchase a prepaid credit/debit card, to pay down a balance on a 
credit card, or to add credit to a bank account associated with a debit card. To use these 
handlers 160-2, 160-3, the payment enabler 170 stores the information for receiving 
money from credit or debit cards m the conventional way, such as the account number, 
expiration date, name, and/or PIN. Similar information may be used when paying-out 
money to a credit/debit card. 

The bank handler 160-4 allows electronic fimds transfer (EFT) of money 
to a bank accoxmt of the user. The user enters the account number and routing 
information into the payment enabler 170 with a user interface 180 to facihtate adding 



and removing of money from the payment enabler with this handler 160-4. In one 
embodiment, an automated teller machine (ATM) could incorporate the bank handler 
160-4 along with an ATM interface 180-1 to allow adding and removing funds along with 
interfacing with the payment enabler 170. Another embodiment uses a bank handler 160- 
5 4 branch location as a retail interface 180-4 for interacting with the payment enabler 170. 
Some embodiments could wire money into a bank account of the user instead of an EFT. 

The retail handler 160-5 typically corresponds to a retail location 500 or 
storefront that may wire money, print money orders and/or cash checks. Money may be 
sent to the retail handler 160-5, whereafter the user is issued cash or a negotiable 
10 instrument for that money. Money can be added to the system 100 by the retail handler 
1^. 1 60-5 also. For example, the user may give cash to the clerk at the retail location 500 

^ who enters a credit into the payment enabler. The user could fiirther specify to the clerk a 

^ receiver who should get the money. A retail interface 1 80-4 at the retail location 500 or 

|i| bricks and mortar location is used by the clerk to indicate to the payment enabler 170 that 

W 15 the money has been received from or by the user. Through an retail handler 160-5 a 

IJ'i 

s sender 110 could use the online money transfer system 100 without any knowledge of 

SI computers or without any debit/credit card or bank account. 

f ^ Gift certificates are dispensed through one or more gift certificate handlers 

p 160-6. The gift certificate can be limited to merchandise and^r services firom a single 

^' 20 store or a group of stores. In some cases, the gift certificate is used only online by 

entering a code provided to the receiver or could be printed for use in a bricks and mortar 
store. Cash equivalents such as Flooz^'^, formerly available from Flooz.com, could also 
be provided to the receiver 130. For example, a hsting on the vending site 140 may 
specify that the compensation should be m the form of a particular gift certificate. 
25 As briefly discussed above, the ATM interface 180- 1 allows interaction 

with the payment enabler 170. The user may 1 10, 130 or may not have an affiUation with 
the ATM that is used to interface with the payment enabler 170. Under this circumstance, 
the owner of the ATM may charge the user a fee for this service. The user 110, 130 can 
receive cash or deposit cash if the ATM is coupled to a bank handler 160-4. In any event, 
30 the ATM interface 180-1 can be used to interface with the payment enabler 170 in the 

same way a user 1 10, 130 may interact through a web browser and computer 120 with the 
payment enabler 170. If the ATM has a magnetic stripe or smart card reader, this could 
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be used by to avoid entering credit or debit card information manually for the payment 
enabler 170. 

A kiosk interface 180-2 allows a user to interact with the payment enabler 
170, but typically does not allow adding or removing cash. The kiosk interface 180-2 
5 may be a browser terminal available for general use. Some embodiments may include a 
check or money order printer for removing money from the system 100. The kiosk 
interface 180-2 could be in a retail location 500 and linked to the other systems in the 
retail location 500 such that a payout could be provided by other systems in the retail 
location 500. 

10 An Internet interface 180-3 is typically implemented through a web 

yj browser. The browser downloads web pages from the payment enabler 170. This 

^ browser may reside on the computer 120 of the sender or receiver 1 1 0, 1 30. Some 

y embodiments could host the Internet interface on a portable device such as a wireless 

p phone or personal digital assistant (PDA). The Internet interface 180-3 may also be used 

jjj 1 5 by the ATM, kiosk and retail interfaces 180-1,1 80-2, 1 80-4 in whole or in part. The 
I- Internet interface 180-3 uses encryption for the link to the payment enabler 170 in some 

fij embodiments. 

f J The retail interface 1 80-4 allows for specialized interaction by a clerk at 

Ci the retail location 500. Clerks typically have special training and offer enhanced services 

20 over most interfaces 1 80 and h^idlers 160. The clerk can move money between senders 
110 and receivers 130 at the direction of the user. Also, the clerk can pay-in and pay-out 
money from the fransfer system 100 for any user. The retail interface 180-4 allows an 
clerk to act on behalf of the user when manipulating the user's account. For security, the 
user's password or PIN may be entered during this manipulation. Further, the clerk may 
25 verify the identity of the receiver 130 before disbursing the any money from the fransfer 
system 190. In one embodiment, a test question is provided by the sender 110 that the 
receiver 130 must answer before the elecfronic gift is paid-out. 

Interaction with the payment enabler 1 70 may also be performed over a 
telephone 140 interfaced to the plain-old telephone system (POTS) 155. The phone 
30 interface 180-5 provides voice prompts and recognizes the user's touch-tone or speech 
recognized input. Enhanced interaction with the phone interface 180-5 could be provided 
with wireless phones having wireless access protocol (WAP) and/or browser graphical 
user interfaces (GUIs). 
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Referring to FIG. 3, a block diagram of an embodiment of a payment 
enabler 170 is shown. The transfer of money between handlers 160, stored value funds 
and users 110, 130 is controlled by the payment enabler 170. The pajnnent enabler 170 
may be implemented on one or more computers in one or more locations where the 
various computers communicate over a network. Included in the payment enabler 170 are 
a payment controller 304, handler interfaces 308, a billing function 312, a messaging 
function 316, an enabler interface 320, a user database 324, a payment conversion 
function 328, an exchange rate database 332, and a metalink tool 336. 

The pa3nnent controller 304 manages operation of the payment enabler 
170. The handlers 160 and interfaces 180 along with user information and money 
conversion tasks are all choreographed by the payment controller 304. The payment 
controller 304 is interconnected to the other portions of the payment enabler 170 by one 
or more networks. 

The payment conversion function 328 allows converting between disparate 
forms of money as it is transferred through the transfer system 190. An exchange rate 
database 332 holds conversion factors that allow determining the proper weight to give 
one form of money with respect to the others. In one example, the payment conversion 
function 328 may convert money in U.S. dollars to money in European Union Euros. In 
another example, a user may convert money into airline miles at the rate of eight miles for 
every dollar for a promotion handler 160-1. The exchange rate database 332 is updated 
with conversion rates as often as practical using conventional methods. The conversion 
rate may accommodate a percentage service fee for the exchange, or instead of a 
conversion rate, a flat fee could be charged. 

A billing fimction 312 monitors and charges for the services of the 
payment enabler 170. There may be charges when transferring money, converting 
money, sending electronic gifts, printing and mailing negotiable instruments, using 
kiosks, ATMs or retail locations, inserting snippets into listings on vending sites 140, etc. 
These charges are normally deducted from a transfer, but other embodiments could 
charge monthly fees or use based fees. Some embodiments could recover a fee from the 
handler 160. For example, a fee could be charged to the gift certificate target store 
instead of charging the sender 110. The different types of handlers 160 may have 
different fees associated with them. For example, a credit card may have a three percent 
charge, but a bank transfer may only have a one percent charge. The sender and/or the 
receiver can be charged to transfer money between themselves. Further, a charge from 



the money transfer could be funneled back to the vending site 140 to pay for the hsting. 
The transfer in or out of the system 100 may incur a separate charge. The billing function 
312 may issue invoices for some users. 

There are handler interfaces 308 to support the various handlers 160. Each 
of these interfaces 308 may support a single handler 160 or a group of handlers. For 
example, a single interface may perform EFT both to and from all bank handlers 160. 
When money is sent to or received from a handler 160, the appropriate handler interface 
308 passes the money and transfer information to the payment controller. In some 
embodiments, the cost of the fransfer to or from the handler is reported by the handler 
interface 308 such that the billing function could recover those costs as a fee to the buyer 
110 or seller 130. 

Information for the users of the system 100 is stored in the user database 
324. This information includes an address book of other users, money credit in the stored 
value fund, past money transfer information, account number, e-mail addresses, contact 
information, vending site login information, snippet information and preferences, 
customized snippet messages, handler interface information, handler preference 
information, etc. The money credit is stored in a trust account for the benefit of the user 
according to the entry in the user database 324 corresponding to that user and interest 
may or may not be paid on that money credit. 

Money is a credit amount stored as a database entry corresponding to the 
user in the user database 324. The database entry corresponds to a stored value fund for 
that user that can be supplemented by transferring-in credit or reduced by transferring-out 
credit. The money or credit is transferred between users by updating the database entries 
for the users involved in the transfer. Money could be in any currency or be an)^hing of 
monetary value, for example, airline mileage, promotional program points, gift certificate 
credit, commodities such as gold, etc. 

Some embodiments may not used stored value funds. In these 
embodiments, money transfers to the receiver 130 pass directly to the money handler 160 
specified by the receiver 130. The receiver has the option of having the money transfer 
once it clears or immediately. Where the transfer is immediate, transfers that fail could 
be absorbed by either the receiver 130 or the payment enabler 170 if insurance is 
purchased. 

The enabler interface 320 is used by the various interfaces 1 80 to interact 
with the user. The enabler interface 320 produces the form web pages and informational 
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web pages to allow the user to create and maintain their account, transfer money, select 
electronic gifts, configure vending site snippets, and learn to use the system 100. The 
appropriate user interface 180 formats and processes the enabler interface information 
according to the device used to interface with the payment enabler 170. For example, the 
Internet interface 180-3 takes the information ftom the enabler interface 320 and formats 
into hypertext mark-up language (HTML) appropriate for the computer 120 of the user. 

A messaging function 316 is used with some configurations to notify the 
user of certain events. Requests for money are sent by the messaging function 316 along 
with acknowledgment and billing messages. These messages could be accessed using a 
web browser, an e-mail program, an instant messaging program, a pager, a WAP enabled 
device, etc. In some embodiments, the messaging function 316 may issue printed bills for 
users. The messaging function 316 is also used to communicate with retail locations 500 
and with the eCard site 140. Some embodiments use the metalink tool 336 to formulate a 
money request to the buyer 110 after a listing matures at the vending site. 

The metahnk tool 336 manages formulation of snippets, automated 
insertion of those snippets at the vending site, gathering information about the listing, and 
formulating money requests for a listing. Electronic listings, such as classified ads and 
auctions, are managed by the metalink tool 336 for the benefit of a seller 130. Goods or 
services offered in a hsting can be paid for using the payment enabler 170. 

The metalink tool 336 gathers information on each listing fi-om the seller 
130, the vending site 140, tiie buyer 110, and any information stored in the user database 
324 in the past. Information gathered and stored in the user database 324 for each listing 
could include a shipper selection, shipping insurance cost information, an address for the 
seller, tax information, an item description, a reference number, a payment enabler 
category, a purchase price, a phone number for the seller, a close date for the Hsting, and 
a quantity of items in the hsting. After the listing closes, information such as the address 
of the buyer, the e-mail address of the buyer, the shipping selection, the insurance 
selection, a purchase order number, special handling mstructions, and other information 
could be added to the user database 324. 

In a listing, the seller 130 often whishes to indicate the forms of payment 
accepted. A branded graphic or button can accomphsh this. By way of the enabler 
mterface 320, the seller 130 interacts with the metalink tool 336 to insert a snippet of 
HTML code that references a graphic for display. This graphic can be made into a button 
by including a link or a universal resource identifier (URI) tiiat is loaded into the browser 



when the graphic is choked upon. The metahnk tool 336 stores login information for any 
number of vending sites associated with each seller 130 in the user database 324. The 
login information allows the metalink tool 336 to automatically insert the snippet into the 
current hstings of the seller 130 and/or all future listings of the seller 130. Some 
5 embodiments just list the HTML code of the snippet in a web page that the seller 130 can 
cut and paste into a listing. In some cases, the snippet may include a custom message 
from the seller 130 that is either visible all the time or only when the cursor hovers over 
the graphic. 

The Unk can include information about the listing to make the process of 

10 sending money to the seller 130 easier. In one embodiment, a code unique to that listing 
is inserted into the link. That code is used to query the user database 324 for information 
CI on the listing. Another embodiment includes fields ui the link that hold some or all of the 

rj information relevant to the listing. 

Jl: Here is an example of a snippet that might be automatically inserted or 

M 

y 15 manually pasted into a listing: <forra name- 'fhnMZSubmit" method- 'POST" 

m 

action="http://fdcdevwevl/HSPaymeSignon.asp"> <input type-'hidden" name= 
O "hdnMZUserlD" value="3 1 8 1 "> <input type="hidden" name="hdnAmount" 

|i value="34"> <input type="hidden" name="hdnSubject" value="ParkieBaby"> <input 

ji{ type="hidden" nanie="hdnReferenceNumber" vahie="223453389"> <tr><td colspaQ="2" 

tU 20 align="center"> <input type="impage" name-'imgSubmif ' 

src="http://www.moneyzap.com/images/logo_lg.gif'x/td></tr></form>. Specified in 
this snippet are the payment enabler user identifier for the seller 130, the purchase price 
of $34, the subject of the Usting of "ParkieBaby," the reference nimiber for the listing of 
"223453389," a link back to the payment enabler 170, and a graphic for the button. 
25 Although this embodiment uses HTML and scripts, any combination of web languages 
could be used such as ActiveX'^'", Java"^", scripting languages, etc. Other embodiments 
could embed more information in the link that is provided to the payment enabler 170 
when the link is presented as is known in the art. 

The metalink tool 336 can track the listing to determine when it has 
30 matured for sale. For example, an auction may have a closing date while a classified ad is 
mature so long as the item is not sold. When a hsting matures, the metalmk tool 
automatically gathers the sale price, the buyer 110, the e-mail address of the buyer, the 
shipping amount, a listing description, a reference identifier used by the vending site, and 
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any other informatioii available from the vending site 140. Some embodiments 
automatically compose a message with an embedded snippet that is sent to the buyer 130 
soliciting money from the payment enabler. The seller can customize tiie contents of this 
message in one embodiment. 

With reference to FIG. 4, a block diagram of an embodiment of a vending 
site 140 is shown. The vending site 140 works in concert with the money transfer system 
190 to allow paying the seller for whatever is offered in the listing at the vending site 140. 
The vending site includes a site controller 404, a web interface 408, a user database 416, 
and a listing database 412. 

The site controller 404 manages the functions of the vending site 140. The 
web interface 408 allows interaction with information in the Usting database 412 and user 
database 416. Both the sender and receiver 1 10, 130 interact with the web interface 408 
to browse listings or enter listings. Any account information on the sender and receiver 
1 10, 130 is stored in the user database 416. The hsting database 416 stores the listings of 
the sellers 130. 

The site controller 404 allows adding information to listings, determining 
contact information for a buyer, and searching for listings of a particular seller. These 
functions are typically meant for manual interaction through the web interface 408. The 
metahnk tool uses these fimctions in an automated way to extract the information relating 
to transferring money. In some embodiments, the vending site 140 may have special 
interfaces designed for automated interaction with software robots gathering information. 

Referring next to FIG. 5, a flow diagram of an embodiment of a process 
500 for adding snippets to listings on the vending site is shown. The depicted portion of 
the process begins in step 504 where the seller 130 logs into the payment enabler 170 
with a user interface 180. In step 508, a graphic is chosen that will act as a button when 
coupled with a link. A determination is made in step 510 as to whether the snippet will 
be manually or automatically inserted in listings. In this embodiment, manual insertion is 
done one listing at a time, but automatic insertion is done for all listings. In automatic 
mode, some embodiments could query the vending systems to present a column of 
listings that the seller 130 could select individual listings to receive the snippet. 

Where a single snippet for manual insertion is selected in step 510, 
processing continues to step 512-1 where a web page is presented to the seller 130 for 
entry of information that is associated with the Hsting. These fields could include 
specification of shipping options, shipping insurance cost information, an address for the 
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seller, tax information, an item description, a reference number, a payment enabler 
category, a purchase price, a phone number for the seller, a close date for the listing, and 
a quantity of items in the Usting. Some fields, such as the purchase price may be left 
blank. In step 516-1, the seller 130 can enter a special message that is presented beneath 
the snippet or as the cvirsor passes over the graphic. For example, this message could say 
"Multiple Items Shipped at No Extra Cost" or some other message. 

In step 520, the information is processed to produce a snippet. The snippet 
includes fields that will be used when presenting the details of the transaction to the buyer 
1 10 for approval. The snippet is manually cut fi-om the web page of the payment enabler 
170 for pasting into the vending site in steps 528 and 532. In some cases, the seller 130 
may modify the fields in the snippet. Whatever ends up in those fields is presented to the 
buyer in a pre-populated money transfer window when the purchase process begins. 

Referring back to step 510 and the case where automatic insertion is 
selected, processing proceeds to step 512-2 where a potentially different set of optional 
fields are presented to the seller 130. With automatic snippet insertion, there are 
potentially many listings that are updated so fields unique to a particular listing are not 
entered in step 512-2. Information that is entered includes specification of shipping 
options, shipping insurance cost information, an address for the seller, tax information, 
and a phone niimber for the seller. Some of these fields may be pre-populated with 
information firom the user database 324, which would allow modification by the seller 
130. Most of the remaining information can be mined fi-om the vending site 140 by the 
metalink tool 336. Any special instructions are entered in step 516-2. These instructions 
are visible in all the listings where snippets are inserted. 

In step 536, login information is provided to the metalink tool 336 for all 
the vending sites 140 that have listings needing snippets. This login information is stored 
in the user database 324 for next time. They seller can enter individual Ustings by their 
identifier for each vending site 140 or can specify a global insertion for all listings 
associated with the login information in step 540. Some embodiments search the vending 
sites 140 for listings and present a web page that shows the listings and allows selection 
of individual listings, all hstings on a particular vending site or all listings on all vending 
sites. In step 544, the metalink tool 336 inserts buttons into the Ustings specified in step 
540. 

With reference to FIG. 6, a flow diagram of an embodiment of a process 
600 for a buyer 110 paying for goods and/or services in the hsting is shown. The 
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depicted portion of the process begins in step 604 where the Usting matures. With 
classified advertisements, the listing matures once it appears on the vending site 140. But 
with most auctions, the buyer is not determined until the close of the auction period at 
which time the listing matures. In some embodiments, a classified advertisement can 
become stale when the listing is already sold or after some time period. In those 
circumstances, the metalink tool 336 could change the graphic to indicate unavailability 
or could contact the vending site 140 to remove the listing. 

Once the listing has matured, the graphic for the button reflects in step 608 
that payment can be made now to purchase the goods and/or services in the listing. In 
step 610, the metalink tool 336 gathers information about the closed hsting such as final 
price, buyer user identifier, buyer e-mail address, etc. for storage in the user database 324. 
If the buyer user identifer for that vending site 140 is foxmd in the user database, 
additional information can be determined for the transaction. There are three options for 
proceeding with pajmient fi-om step 612, namely, the payor manually goes to the payment 
enabler, the payor uses the button to go to the payment enabler, or the payee sends a 
money request to the payee. 

Where an automated request from the buyer 110 for money is prepared, 
processing continues from step 612 to step 620 where a money request message is sent to 
the buyer 110. In this embodiment, an e-mail message is formulated and sent, but other 
embodiments could use a message on a web page, an instant message, a pager message, a 
wireless phone message, or other electronic message to request the money. The message 
includes a link to the payment enabler in a snippet. The snippet has embedded 
information relating to the transaction, such as a shipper selection, shipping insurance 
cost information, an address for the seller, tax information, an item description, a 
reference number, a vending site identifier, a payment enabler category, a purchase price, 
a phone number for the seller, a close date for the listing, a quantity of items in the listing, 
a buyer user identifier, a buyer e-mail address, a buyer address, and/or an account number 
of the buyer for the payment enabler. Alternative embodiments may instead include a 
code that references the transaction information stored in the user database 324 such that 
in either case it is available to pre-populate forms for sending money. 

In most cases, the payor activates the link in the snippet to direct their web 
browser to the payment enabler 170 and to reference transaction information. In some 
cases, however, the payor 110 will manually point their browser to the payment enabler 
170 without the benefit of the information embedded in the snippet. In step 628, the 
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information from the snippet and/or user database is used to pre-populate information 
fields for the money transfer. Things that typically are used in a person-to-person money 
transfer include information on llie seller, on the transaction and on the buyer. Certain 
information available may be shielded from the buyer 1 10 or seller 130 to protect privacy. 

In step 632, a web page is formulated to allow the authorization of sending 
money to the payee. All fields are populated with any gathered information, but some 
fields may be modifiable, such as the shipping information, money handler information, 
insurance for the shipping, the quantity, any special instructions to the seller, etc. Any 
fields that are missing information are populated by the buyer 1 10 in step 636. Some 
non-essential fields may be left blank by the buyer 110. In step 640, electronic 
notification is sent to the seller that payment has been received. The payment is 
transferred in step 644 from the money handler of the buyer to the stored value account of 
the seller. 

As mentioned above, it is possible for the buyer to manually browse to the 
payment enabler 170 without using the link in the snippet by proceeding from step 612 
directly to step 632. Under this circumstance, the payment enabler does not know the 
listing being paid for. In one embodiment, the buyer sends money to the seller in the 
traditional way. In another embodiment, the buyer enters a vending site and Usting 
identifier so that information stored in the user database 324 is used to pre-populate 
forms. In any event, processing continues through steps 632 , 636, 640 and 644 as with 
the embodiment where a money request is sent to the buyer discussed above. 

A third alternative from step 612 involves the buyer activating the button 
in the snippet on the vending site 140. After maturing, the button in the Usting can be 
activated in step 624 as in the money request embodiment discussed above. From step 
624 and beyond processing proceeds as in that money request embodiment. 

Referring next to FIG. 7, a flow diagram of an embodiment 544 of a 
subroutine for automatically inserting snippets in listings is shown. In this embodiment, 
the seller 130 has chosen automatic insertion of snippets for specific listings or all hstings 
on a one-time basis or for all listings going forward. In step 702, a determination as to 
whether there are only specified hstmg(s) or a search for hstings should be done. If a 
search is specified, it is performed in step 704. That search can be performed on one or 
more vending sites 140. 

Regardless of how the Hstings are found, information is gathered in step 
708 about those listings. Information such as the type of listing, any closing date, the 
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subject of the listing, the quantity, and any other information is gathered. The gathered 
information is stored in the user database 324 in step 712. For each listing foimd, a 
customized snippet is formulated in step 716. Those snippets are inserted in their 
respective listings in step 720. If a one-time insertion is requested, processing from step 
724 ends until another request is made by the seller 130. If the seller specifies perpetual 
insertion, processing goes from step 724 to step 728 to wait for the next insertion cycle. 
In this embodiment, the insertion process is run once a day to look for and insert snippets 
in new Ustings. Other embodiments may use other periods or could have the period be 
specified by the seller 130. 

While the principles of the invention have been described above in 
connection with specific apparatuses and methods, it is to be clearly understood that this 
description is made only by way of example and not as limitation on the scope of the 
invention. 
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